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"A Financial Risk and Exposure Management System" 
INTRODUCTION 
5 Field of the Invention 

The invention relates to a system for management of financial risk or exposure. 
Prior Ait Discussion 

10 

In recent years, organisations such as financial institutions have increasingly entered into 
agreements with third parties in order to reduce exposure for deals such as derivatives 
deals. One example is close-out netting. A close-out netting agreement is made between 
a financial institution and a counterparty. It states that in the event of counterparty 
15 default, the total position with that counterparty will be treated as the result of close-out 
all qualifying contracts. Thus, the financial institution exposure in the event of 
counterparty default is the netted sum of all trades covered by a close-out netting 
agreement. Therefore, there is a single balancing amount to be paid by one party. 

20 While such agreements are very important instruments for financial institutions and other 
similar organisations, administration is particularly difficult. This is because of the 
financial and legal complexities involved. For example, close-out netting agreements are 
only legally allowable in a certain limited number of countries. Also, within these 
countries various constraints apply. 

25 
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It is therefore an object of the invention to provide a financial risk or exposure 
management system which manages the creation and maintenance of agreements in a 
manner which is both effective and minimises user time input required. 

5 SUMMARY OF THE INVENTION 

According to the invention, there is provided a financial risk and exposure management 
system comprising a user interface comprising means for receiving user data for a 
proposed transaction, and a modelling engine comprising means for determining 
10 eligibility of the proposed transaction to an agreement with a counterparty. 

Preferably, the modelling engine comprises means for accessing static tables storing 
eligibility data. 

15 In one embodiment, the static tables comprise tables containing master agreement, 
eligible countries, eligible branches, and eligible product data. 

In another embodiment, the modelling engine comprises means for accessing dynamic 
tables storing agreement data for existing agreements and counterparties. 

20 

In one embodiment, the modelling engine comprises means for accessing secondary 
dynamic tables storing data for groupings of correlated parameters. 

Preferably, the engine comprises processing means for operating according to rules to 
25 access the static and dynamic tables in a controlled manner to generate a proposal 
response. 

In another embodiment, the processing means comprises means for executing a 
controlled sequence of tests comparing the received user data with data in the static and 
30 dynamic tables until an eligibility status flag is set to positive. 



Preferably, the modelling engine comprises means for executing a test in both static and 
dynamic tables for each proposal attribute. 

5 In one embodiment, the modelling engine comprises means for operating in a fixed 
sequence of tests, in which each test has an associated date access address for fast 
response times. 

In another embodiment, the modelling engine comprises means for automatically 
10 performing an exposure calculation if the status flag is positive. 

Preferably, the calculation generates a set of projected exposure values for future deal 
dates. 

15 According to another aspect the invention provides a computer program product 
comprising software code for completing a system as defined above when loaded in a 
digital computer. 

20 

DETAILED DESCRIPTION OF THE INVENTION 
Brief Description of the Drawings 

25 The invention will be more clearly understood from the following description of some 
embodiments thereof, given by way of example only with reference to the accompanying 
drawings in which:- 

Fig. 1 is a schematic overview of a financial risk and exposure management 
30 system of the invention; 
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Fig. 2 is a diagram illustrating a part of the system for processing close-out 
netting agreements; 

5 Figs 3(a) and 3(b) are together a flow diagram illustrating operation of the part of 

the system shown in Fig. 2; and 

Figs. 4 to 13 are sample display screens to illustrate operation of the system. 
10 Description of the Embodiments 

Referring to Fig. 1, there is shown a risk and exposure management system 1. The 
system 1 comprises a central server 2 having a global exposure and limits database 3. 
This database is updated in real time by geographically spread dealing systems, indicated 
15 generally by the numeral 4. Each of these systems comprises a market risk engine and a 
reporting system which both interact in real time with the central server 2. In addition to 
real time financial data updating, the systems 4 also input parameter values such as pre- 
deal limit checks, exposure updating, and violation alerts. 

20 The dealing systems and the server are programmed to manage exposures dynamically, 
rather than simply imposing limits. This is achieved by combining one or more contract 
attributes or derived values such as Counterparty, Country, Currency, or Product to form 
an exposure consolidation key. This key identifies an exposure consolidation category 
and associated rules process. 

25 

A major function performed by the server 2 is close-out netting management. This 
functionality is performed by a sub-system 1 1 shown in Fig. 2. 

A data capture interface 12 is programmed to interactively prompt user input of data for 
30 proposed agreements and transactions and other query data. The sub-system 1 1 also 
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comprises a modelling engine 13 which comprises a processor operating in response to 
rules to interrogate various datasets and provide outputs to the user. The datasets 
comprise a current dataset 14 of user- inputted data for a particular query or proposal 
agreement. It also comprises a set of dynamic tables 1 5 and a set of static tables 16. 

5 

The sub-system 1 1 also comprises a modelling output interface 17, and a sample output 
18 is illustrated in Fig. 2. 

A table of Master Agreements is maintained containing:- 
1 0 The master agreement identification code 

The agreement name 

Indicators for additional constraints on the attributes. 
Branches of the parent bank 
Dealing product types 
1 5 Currencies 

If an additional constraint is required an associated table is constructed holding the 
authorised values for that attribute for this master agreement. An associated table holding 
the authorised list of jurisdiction countries for this master agreement is maintained. 
20 These tables change relatively infrequently and are therefore referred to in this 
specification as "'static" tables 16. 

A table of counterparty close-out agreements is maintained containing:- 

25 Counterparty identification code 

Agreement identification code 

Master agreement identification code 

Country of applicable law 

Effective date of agreement 
30 Collateral Annex Indicator 
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Current Collateral Value 

Indicators for additional constraints on the attributes 
Currencies covered by this agreement 
Products covered by this agreement 
5 Branches of the parent bank covered by the agreement 

Branches of the counterparty covered by this agreement 

If any additional constraints are required an associated table is constructed holding the 
authorised values for that attribute for this specific agreement. These tables are amended 
10 frequently in response to generation of new agreements and modification of existing 
ones. The counterparty agreement table and these subsidiary tables are therefore referred 
to as "dynamic" tables 15. The dynamic tables are essentially subsets of the static master 
agreement table and its subsidiary static tables. 

15 Referring to Figs. 3(a) and 3(b) a process comprising steps 25 to 39 is now described. 
This process is carried out by the modelling engine operating 13 according to rules 
defining a controlled process and accessing the static and dynamic tables. 

An important aspect of the modelling engine 13 is that it operates in a highly controlled 
20 manner to follow a test execution sequence such as that illustrated in Figs. 3(a) and 3(b). 
Each rule which requires data access is coded with the address of the relevant table. 
Because the datasets are in dynamic and static groups, and because the dynamic tables 
have subsidiary tables identified by parent dynamic table records there is very fast data 
access. Also, there are secondary tables which correlate groupings of related data. This 
25 minimises the number of accesses required. Thus, in most instances, a rule can access 
required data derived from a correlation of, for example, an agreement and a counterparty 
in a single access in which time is delayed only by a single index and table access cycle. 
These features allow excellent real time performance of the system, even if there are 
thousands of counterparties. 



30 
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The data capture interface 12 receives user data for a proposed transaction. In step 25 the 
engine checks if the proposal is eligible for close-out netting treatment under an existing 
agreement with the relevant counterparty. The data captured for this purpose is:- 

5 Counterparty Identification Code 

Counterparty HQ Country 

Product code 

Dealing branch code 

Dealing Branch Country 
10 Counterparty branch or location code 

Counterparty branch country 

Currency code or codes of the transaction or contract 

If no agreements are found then a Close-out Netting Status is set to NO, as indicated by 
15 step 26. If an agreement is located, the engine 13 then checks each agreement for this 
counterparty against the process steps below until it determines that the close-out status is 
YES. If the agreement list is exhausted before this condition is found then the close-out 
status is NO and a process exit is taken. If the close-out status for an agreement is set to 
YES the process exit is taken. 

20 

Location of an agreement is indicated in step 27, and in step 28 the current date is 
checked against the effective date. If the effective date is in the future the process returns 
to step 27. 

25 The country of applicable law is checked in step 29 against the list of authorised 
jurisdictions for the designated master agreement. If the country is not included in the 
authorised list the process returns to step 27. 
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The country of counterparty HQ is checked in step 30 against the list of authorised 
jurisdictions for the designated master agreement. If the country is not included in the 
authorised list the process returns to step 27. 

5 The product attribute constraint indicator is checked in step 31. If a product constraint is 
in effect the product code is checked against the list of authorised products for this 
counterparty close-out agreement. If the product code is not found in this list the process 
returns to step 27. The product attribute constraint indicator for the associated Master 
Agreement is checked in step 32. If a product constraint is in effect the product code is 
10 checked against the list of authorised product for this master agreement. If the product 
code is not found in this list the process returns to step 27. 

The dealing branch attribute constraint indicator is checked in step 33. If a dealing 
branch constraint is in effect the dealing branch code is checked against the list of 
15 authorised dealing branches for this counterparty close-out agreement. If the dealing 
branch code is not found in this list the process returns to step 27. 

The dealing branch country code is checked in step 34 against the list of authorised 
jurisdiction countries for this master agreement. If the dealing branch country code is not 
20 found in this list the process returns to step 27. 

The counterparty branch attribute constraint indictor is checked in step 35. If a 
counterparty branch constraint is in effect the counterparty branch code is checked 
against the list of authorised counterparty branches for this counterparty close-out 
25 agreement. If the counterparty branch code is not found in this list the process returns to 
step 27. 

The counterparty branch country code is checked in step 36 against the listed of 
authorised jurisdiction countries for this master agreement. If the counterparty branch 
30 country code is not found in this list the process returns to step 27. 
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The currency attribute constraint indicator is checked in step 37. If a currency constraint 
is in effect the currency code is checked against the list of authorised currencies for this 
counterparty close-out agreement. If the currency code is not found in this list the 
5 process returns to step 27. 

The currency attribute constraint indicator for the associated Master Agreement is 
checked in step 38. If a currency constraint is in effect the currency code is checked 
against the list of authorised currencies for this master agreement. If the currency code is 
10 not found in this list the process returns to step 27. 

The close-out netting status is then set to YES and the process returns to step 27. 

The engine 1 3 then proceeds to calculate the counterparty credit value of transactions in a 
15 proposed agreement provided the status is YES. The data capture interface 12 captures 
the following data:- 

Counterparty code 

Close-out Netting agreement identifier 
20 Transaction Mark to Market value (MtM) 

Transaction Potential Future Exposure value (PFE) 
Transaction exposure maturity date 

For all transactions with the same counterparty code and close-out netting agreement 
25 identifier code the engine calculates:- 

The sum of all the MtM values and the sum of all positive MtM values. 

A mitigating factor (MF) is calculated using the formula 0.4 + 0.6* sum of all 
30 MtM values divided by the sum of all positive values. 
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The counterparty credit risk of all transactions included in the close-out netting 
agreement is calculated from the formula:- 



Maximum (sum of all MtM values or Zero) +sum of all PFE values 
multiplied by the mitigating factor. 



The counterparty credit risk value of all transactions which are still active o any future 
date is calculated by summing the MtM values and PFE values for all transactions on that 
10 date where the transaction exposure maturity date is later than the selected date. A 
sample output is shown in Fig. 2. 

Referring now to Figs. 4 to 13 system display screens are shown to assist in 
understanding the composition of the tables and the manner in which the modelling 
15 engine operates. Editing of a closeout agreement table is shown in Fig. 4. This table 
includes markers or flags for related tables for currencies (Fig. 5), products (Fig. 6), 
branches (Fig. 7), and locations (Fig. 8). These tables are all dynamic. There are also 
secondary dynamic tables for groupings or correlations of data such as a grouping of a 
particular counterparty and a particular agreement. 



The primary static table is a master agreement table, editing of which is shown in Fig. 9. 
Figs. 10 to 13 illustrate related tables as follows: 



20 



25 



Fig. 10 
Fig. 1 1 
Fig- 12 
Fig. 13 



products, 
branches, and 
jurisdiction. 



currencies, 



These tables are updated relatively infrequently. 
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lt will be appreciated that the invention provides for comprehensive agreement 
processing for risk and exposure management. This has been achieved with very fast 
response times to allow real time operation where workstations are widely spread 
geographically. 

The invention is not limited to the embodiments described, but may be varied in 
construction and detail within the scope of the claims. For example, the invention may- 
be applied to processing of agreements between counterparties other than close out 
netting agreements, such as general netting agreements. 



A financial risk and exposure management system comprising a user interface 
comprising means for receiving user data for a proposed transaction, and a 
modelling engine comprising means for determining eligibility of the proposed 
transaction to an agreement with a counterparty. 

A system as claimed in claim 1, wherein the modelling engine comprises means 
for accessing static tables storing eligibility data. 

A system as claimed in claim 2, wherein the static tables comprise tables 
containing master agreement, eligible countries, eligible branches, and eligible 
product data. 

A system as claimed in any preceding claim, wherein the modelling engine 
comprises means for accessing dynamic tables storing agreement data for existing 
agreements and counterparties. 

A system as claimed in claim 4, wherein the modelling engine comprises means 
for accessing secondary dynamic tables storing data for groupings of correlated 
parameters. 

A system as claimed in any preceding claim, wherein the engine comprises 
processing means for operating according to rules to access the static and dynamic 
tables in a controlled manner to generate a proposal response. 

A system as claimed in claim 6, wherein the processing means comprises means 
for executing a controlled sequence of tests comparing the received user data with 



data in the static and dynamic tables until an eligibility status flag is set to 
positive. 

A system as claimed in claim 7. wherein the modelling engine comprises means 
for executing a test in both static and dynamic tables for each proposal attribute. 

A system as claimed in any of claims 6 to 8, wherein the modelling engine 
comprises means for operating in a fixed sequence of tests, in which each test has 
an associated date access address for fast response times. 

A system as claimed in any preceding claim, wherein the modelling engine 
comprises means for automatically performing an exposure calculation if the 
status flag is positive. 

A system as claimed in claim 10, wherein the calculation generates a set of 
projected exposure values for future deal dates. 

A system substantially as described herein with reference to the drawings. 

A computer program product comprising software code for completing a system 
as claimed in any preceding claim when loaded in a digital computer. 
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